OHNOLZA 숙박예약서비스 회고록 - 팀빌딩과 환경세팅

(2023년 10월 실시한 프론트엔드 부트캠프의 회고록 입니다)

OHNOLZA 바로가기
레포 바로가기

처음으로 백엔드팀과 협업의 결과물을 만들어냈습니다. 야놀자와 같은 숙박업체 예약 시스템을 만드는 것이 목표였고 리스팅, 예약, 결제(가상), 장바구니, 상세페이지 구현 등이 필수 요구사항입니다. 2주 간 나름 잘 수행하여, 짧은 기간을 생각하면 만족스러운 결과물이 나왔습니다.

모든 팀원들이 열심히 수행해준 덕분에 잘 끝낼 수 있었습니다. 열심히 한만큼 차근차근 회고를 남겨두고 싶은 마음에 오랜만에 글을 써봅니다.

1. 상황 판단과 합리적인 선택

팀빌딩이 되고, 프로젝트에 막 투입될 무렵 우리는 현재상황에 대해서 올바른 판단을 하는게 중요했습니다. 현 상황과 수준에 맞는 스택과 계획을 세워야 2주 안에 숙제를 잘 제출할 수 있기 때문입니다.. 상황을 파악해보자면 다음과 같았습니다.

1. 팀원 평균 실력: 개발자 지망생 각 팀원마다 실력차가 존재하지만, 평균적으로 팀의 실력은 주니어라는 제한사항 존재.

2. 프로젝트 특성 : 첫협업, 제한시간 2주 프로젝트 자체 또한 부트캠프 수강생을 대상으로 하기에 고스펙은 아니지만 양팀간의 협업이 처음이라는 변수를 제한 시간이 2주로 매우 짧음.

양 팀 모두 첫 협업이었기 때문에 커뮤니케이션과 적응 등의 변수가 존재했습니다. 또한, 평균 개발 실력이 높다고 보기는 어려웠습니다. 따라서 각자가 공통적으로 가지고 있는 역량을 최대한 활용하며, 신기술이나 추가 기능에 대해서는 보수적으로 접근하는 것이 옳다고 판단했습니다.

3. 결과 :

• 첫협업에 각자 최대한 빠르게 적응
• 신기술, 추가기능은 보수적으로 접근

2. 스택 설정

위의 판단은 스택 설정으로도 자연스럽게 이어졌습니다. 팀원들이 가장 신경 쓰는 부분은 백엔드와의 협업 중 발생할 수 있는 변수들이었습니다. API 연동과 이후 발생할 수 있는 변수들에 대응할 시간을 고려했을 때, 우선순위가 낮은 부분에서는 힘을 빼는 것이 필요했습니다.

우리는 최대한 빠르게 진행할 수 있으며, 프로젝트 중간에 발생할 변수를 줄이고, 가능한 높은 퀄리티를 기대할 수 있는 선택을 해야 했습니다. 결국, 모두가 현재 잘하는 기술로 개발하자는 결론에 도달했습니다.

3. 화면구성 : 웹앱

모바일 뷰는 꼭 놓치고 싶지 않았습니다. 숙소 예약 서비스는 특정 사용자만이 아니라 대중적으로 사용되는 서비스이기 때문에, 모바일 뷰를 고려하지 않는 것은 매우 아쉬운 상황이었습니다. 그러나 데스크탑 뷰를 모바일 반응형으로 제작하는 것은 생각보다 많은 시간이 소요되었습니다. 또한, 마감 기한에 다다랐을 때 모바일 뷰를 포기해야 하는 상황이 발생할 가능성도 있었습니다.

그렇기에 처음부터 모바일 뷰를 염두에 둔 웹앱 뷰 방식을 채택했습니다. 결과적으로 이는 매우 합리적인 선택이었고, 뷰에 대한 개발 공수를 상당히 줄일 수 있었다고 모두가 느꼈습니다.

4. 브랜치전략 & CI/CD

GitHub Flow

: 브랜치 관리 측면에서 유연한 GitHub Flow를 사용했습니다. 2주라는 짧은 시간과 개발 자체에 보다 더 몰두해야 하는 상황에서 내린 판단이었습니다.

CI/CD : 넷리파이

: 기본적인 환경 세팅이 완료된 후, 메인 브랜치를 넷리파이를 통해 배포했습니다. 넷리파이는 브랜치 등록만 해두면 CI/CD 환경을 자동으로 세팅해줘 편리하게 사용할 수 있었습니다.

이번 프로젝트에서 지속적 배포를 택한 이유는 다음과 같습니다.

안정성

: 프로젝트가 완성된 이후 한 번에 배포하는 경우, 배포 시점에 수많은 디버깅이 요구될 가능성이 존재합니다. 매 병합마다 배포 유효성을 검사하며 지속적으로 배포하는 방식이 더 안정적이고 불필요한 시간을 줄여줄 수 있었습니다.

작은 병합 단위

: 이번 프로젝트에서는 작은 기능별로 PR을 나누었습니다. 따라서 많은 PR이 발생했습니다. 병합 시점에 코드량이 많지 않아, 배포 오류가 발생하더라도 디버깅 시간이 길지 않을 가능성이 높았습니다.

적응 및 속도

: 지속적인 배포 과정을 통해 팀원 모두가 배포 환경과 오류에 적응할 수 있었습니다. 따라서 배포 오류로 인해 개발 속도가 늦춰질 가능성이 점차 줄어들 것으로 기대되었습니다.

빠른 문제 발견 및 수정 가능성

: 작은 단위별로 배포되기 때문에, 문제가 발생할 단위 구간도 좁아집니다. 따라서 배포 오류를 빠르게 발견하고 해결할 가능성이 높았습니다.

5. 정리 및 회고

팀빌딩과 환경세팅을 한 경험을 되돌아보니 아쉬운 부분들이 몇몇 있습니다. 분명 팀의 역량에 맞는 기술들을 채택한 것은 합리적이었다고 볼 수 있습니다. 시간이 짧았고 주니어들로 구성된 팀이기 때문입니다. 하지만 아쉬웠던 것은 팀이라는 내부적인 환경만을 고민했지, 어플리케이션의 특성 자체는 고민하지 못했던 것 아닐까하는 점입니다.

가상의 어플리케이션이긴 하지만, 이것이 실제로 운용된다고 가정했을 때 중요한 부분들이 분명 있습니다. 유저의 접근성을 높여주는 SEO 최적화와 어플리케이션의 준수한 성능이 그러할 것입니다. 이러한 부분들을 생각해봤을 때 NextJS를 채택했으면 어땠을까 생각해봅니다. SEO 또한 유리하게 최적화할 수 있으며, 특성 상 이미지가 많은 페이지에서 이미지 로딩의 장점들도 가져갈 수 있는 스택이기 때문입니다. 이런 부분들을 고려했으면 더 좋지 않았을까하는 아쉬움이 남습니다.